How Exactly do the HTTP 1.0 MIME Types Work (MacHTTP.config)

Chuck says:

MIME stands for Multipurpose Internet Mail Extensions. It's a standard for specifying data types and representations. It was originally designed for extensions to e-mail, but the typing model has been sucked into the HTTP/1.0 standard and is part of the info sent between WWW clients and servers that specifies what types of documents can be handled and what type of data is being returned.

See RFC 1521 for more details.

Chuck says the algorithm goes as follows:

First, MacHTTP attempts to match the suffix of the file name, deriving the MIME type information from whichever line matches the suffix first.

If it can't match the suffix of the file, it runs through the list looking for Macintosh file type matches. If it finds a match, it considers the first match the best one unless a line is found where the type AND creator match. The MIME type information from the line with the best match is then used.

The easiest way to match files to MIME types is (unfortunately) still to use suffix matches. Any file you named with a ".xls" suffix, for instance, would be sent as an application/excel MIME type. Otherwise, you must make an entry for each file type in the application's BNDL resource.

Rick Hough [Rick_Hough@qmmac.read.tasc.com] asked:

If my MacHTTP server says extension .X should be for MIME type Y, but someone's MacMosaic says extension .X maps to MIME type Z, who wins?

Chuck says:

The MIME type wins. The suffix mapping is for servers that don't specify a MIME type, such as FTP hosts, gophers, etc.

Defining Your Own MIME Types

You can make up whatever types you want, but usually user-defined types for non-standard docs are in the form "application/x-some_app_name". I.e., application/x-msword or application/x-authorware.

If MacHTTP sends MIME info for a document that indicates its type is application/x-authorware, the WWW client must have a definition for application/x-authorware that invokes the AuthorWare application.